REMD Workflow Automation #36
Conversation
|
@mattwthompson Do you know the best-practice way to include an OpenEye license for testing with GHAs? I see OpenFF-toolkit has tests with and without OpenEye |
Yeah, you don't want to include OpenEye in any release package. |
…mer systems, next is to build topologies for the entire system
|
In terms of packaging, you want to keep it an optional dependency. Both because your users might not have a license and because you can't bundle it with a released version (licensing details, to my understanding) nor include it as a required dependency, at least with If you want to include it in CI runs, and I'm not totally sure you do, OpenFF's setup is to store a license we're permitted to use in CI (we might have special permission, I don't know the terms of the Shirts license) as an org-level secret that's accessible from actions. (https://github.com/organizations/ORG_NAME/settings/secrets/actions, stored as My $0.02, not knowing what functionality you actually need in automation, is to keep things RDKit/open-source in CI and roll with OpenEye in your local development/production environment. This is how the toolkit is designed to work, including both the high-level API and skipping tests if OpenEye is not installed. |
|
Okay, sounds good! I was asking because I had a testcase that assigns parameters for a small foldamer that would go faster on an install with OpenEye, but since it's using the OpenFF toolkit it can still run without OpenEye, it just takes a bit longer (~40 minutes). I might just skip that test all together when running tests with GHAs. |
|
Yeah, I wouldn't worry about the OpenEye interface. |
…le molecule and musytem topology files. Created a decorator to cd into specific job directories to minimize repeated cd in cd out in flow operation functions
… to call job.doc[build_parameters][foldamer_structure] every time i need to get a name for a file
…ilder object, which fixes the test cases
…eration into different objects, made some utility gromacs wrapper functions that are python functions that call gromacs with their inputs, working on getting connect records correct so I can use openff to parameterize the entire system, rather than writing my own topology file
…opology generators
…s/topologies, next is to add topologies to the internally stored structures
…will be to build and parameterize system using openff toolkit and have those topology files be added to the top manager
…dded tests for topology_manager using unittest, remd_workflow now currently works up until running/submitting simulations
…er_tests now navigate to the test directory before running tests, so that files generated from tests are not left in whatever directory you `run pytest` from
…ll there are no existing test.pkl to load when running the tests
…get Psi4 bespoke-fit workflow working, currently getting segmentation faults when using default QCSpec object
…ion using remd_workflow
…group/terphenyl_simulations into workflow_parameterization
…group/terphenyl_simulations into workflow_parameterization
…rite topology file out
…group/terphenyl_simulations into workflow_parameterization
…instead of running BF workflow
…chemistries and have simulation directories setup for tetramer remd simulations
…s and different import names
…ng in this package
…group/terphenyl_simulations into workflow_parameterization
This PR was merged with PR #35, but this wasn't fully finished. So I'm reopening this PR as I continue to build out the simulation setup workflow. Here is the PR notes from the original PR
Reason for the PR
I think a lot of friction for getting simulations setup and running are because the force field parameter generation and assignment was setup to run in the examples directories, instead of directly in the simulation workflow. This PR is meant to put the simulation setup, running and analysis all in one place. Additionally, this PR is meant to take a lot of the hand tuning required to setup simulations.
Features
analysis_workflowsTo Do's